The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openstatus-dashboard	Ready	Preview, Comment	May 4, 2026 6:49am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
openstatus-status-page	Skipped		May 4, 2026 6:49am
openstatus-web	Skipped		May 4, 2026 6:49am

Deploying openstatus-docs with    Cloudflare Pages

View logs

@claude review

Claude finished @mxkaske's task in 3m 26s —— View job

Code Review: chore/improve-onboarding-flow

Tasks

• Gather context and understand PR scope
• Review core onboarding steps and layout
• Review streaming/data layer
• Review components and forms
• Post final review

This is a well-structured PR. The 3-step flow is clean, the streaming preview adds a compelling "magic moment," and the issues flagged by the previous AI review (phase-sum latency, colSpan, Date.now seed) have all been addressed. Notes below go from most to least significant.

P2 — Substantive

1. Dashboard theme is permanently mutated when the user changes "Mode" then skips
create-page.tsx:211-215

onValueChange={(v) => {
  field.onChange(v);
  setDashboardTheme(v);  // ← persists even if user hits "Do this later"
}}

If the user flips to Dark in the preview and then skips Step 2, their dashboard stays dark. The original theme should be saved and restored on skip/unmount. A useRef for the pre-entry theme + an onSkip callback that calls setDashboardTheme(originalRef.current) would fix this, or the side effect could be scoped to the preview component itself rather than the global theme. Fix this →

2. No rate limiting on /api/onboarding/checks
route.ts

Each call fans out to all ~28 active regions. There's no debounce, cooldown, or rate-limit on the endpoint — a single authenticated user could fire it in a tight loop. The retry button in checks-table.tsx is client-side only, so nothing prevents programmatic abuse. Even a simple per-user per-minute check (or an AbortSignal tied to the monitor ID to cancel a previous in-flight stream before starting a new one) would reduce the blast radius.

3. Second rejection in yieldMany silently overwrites the first
packages/utils/src/stream.ts:20-24

(error) => {
  rejection = { error };  // ← unconditionally overwrites a prior rejection
  pending--;
  wake?.();
},

If two promises reject in the same microtask batch, only the last error survives. For the checker fan-out, individual failures return error-shaped CheckResult objects rather than throwing, so this is rarely hit in production — but it's a silent contract violation worth guarding:

if (!rejection) rejection = { error };

P3 — Minor

4. Locked preview in Step 2 shows stale draft components, not the submitted state
step-2.tsx:119

components={previewValues.components ?? []}

previewValues is only updated through the form's onValuesChange. When isLocked === true, the preview keeps rendering whatever the user last typed, not the saved components. For a decorative preview it's low-risk, but snapshotting previewValues at submit time and using that in the locked branch would be more correct.

5. getServiceContextFromRequest has an unreachable fallback
edge-context.ts:47-50

const activeWorkspace =
  userAndWorkspace.usersToWorkspaces?.find(({ workspace }) => {
    if (workspaceSlugCookie) return workspace.slug === workspaceSlugCookie;
    return true;                     // ← returns the first element
  })?.workspace ?? userAndWorkspace.usersToWorkspaces?.[0]?.workspace;
  //              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  //              unreachable: find with `return true` already returns [0]

The ?? [0]?.workspace fallback is dead code — find(() => true) already returns the first element. This doesn't cause a bug but could mislead a future reader into thinking the two branches have different semantics.

6. emitOnboardingTelemetry calls .mutate() twice on the same instance
client.tsx:170-192

useMutation tracks a single in-flight state; calling .mutate() a second time before the first resolves cancels the first's callbacks. These are fire-and-forget telemetry writes so a dropped callback rarely matters, but using two separate useMutation instances (or mutateAsync + Promise.allSettled) would be more correct.

7. PLACEHOLDER_BAR_DATA computed once at module load time
status-page-preview.tsx:63-76

new Date() is called when the module first loads. On a long-lived session the "45-day" window drifts without a page refresh. For purely decorative placeholder data this is inconsequential, but a useMemo with a stable reference date (e.g. today at mount time) would keep the window current across sessions.

8. safeHostname declared after its call sites
client.tsx:315

It's used at lines 229 and 255 but declared at the bottom of the file. Function declarations are hoisted so this works, but moving it above Client() (or beside slugifyHostname) follows the "define before use" convention and makes the dependency obvious at a glance.

Positive callouts

• The checksStartedRef guard (client.tsx:110-150) correctly prevents double-streaming when React strict-mode double-invokes effects.
• The callbackUrl redirect validation (client.tsx:153-164) is solid — same-origin check + protocol guard + no external-origin navigation.
• The yieldMany settle-as-they-arrive queue implementation avoids the classic Promise.race splice-drop bug and the comment explains the invariant clearly.
• Fixed issues from the prior review are all confirmed resolved (latency now uses result.latency, colSpan now uses table.getVisibleLeafColumns().length, now uses a fixed seed date).
• getServiceContextFromRequest correctly scopes all reads to the authenticated user's workspace.